home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 1779 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: newshost.lanl.gov!tanmoy
  2. From: tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Recursion in C pre-processor ?
  5. Date: 16 Jan 1996 20:19:09 GMT
  6. Organization: Los Alamos National Laboratory
  7. Message-ID: <TANMOY.96Jan16131909@qcd.lanl.gov>
  8. References: <30FC134D.3A8F@powertech.no>
  9. NNTP-Posting-Host: qcd.lanl.gov
  10. Mime-Version: 1.0
  11. Content-Type: text
  12. In-reply-to: Geir Thomassen's message of Tue, 16 Jan 1996 13:06:21 -0800
  13.  
  14. --text follows this line--
  15. In article <30FC134D.3A8F@powertech.no> Geir Thomassen
  16. <geirt@powertech.no> writes: 
  17.  
  18. <snip>
  19.    #define DoFunc(n)\              /* Don't work !! */
  20.    #if n\
  21.       func();\
  22.       DoFunc(n-1);\
  23.    #endif
  24.  
  25.  
  26.    Why ?? Does cpp stop expanding the #if n ... #endif in the first pass 
  27.    if n=0, or does it expand forever ??
  28.  
  29. Two problems with this. First, compiler directives are recognized
  30. _before_ macro expansion, and not after. So, your #if and #endif will
  31. must not be recognized as such by the compiler. (Note also that
  32. backslash newlines are removed far before macro recognition etc.; and
  33. hence the #endif does not appear at the beginning of a line on
  34. expansion.) Of course, as no alternate meaning is possible in this
  35. context, the compiler is free to warn you and then choose to recognize
  36. the directive. Second, a macro name is protected against expansion
  37. when one instance of it is being expanded (or, rather when the
  38. expansion is being rescanned). Thus, the DoFunc(n-1) will not be
  39. expanded further. (And, in this case, there is an alternate meaning:
  40. you may link your code against another compilation unit defining int
  41. DoFunc(int)! So, a compiler must be very careful in interpreting this
  42. in a non-standard way.)
  43.  
  44. As has been repeated often, the C preprocessor is very weak, and
  45. cannot be used to do such variant expansions.
  46.  
  47.    Does anyone have a better (working) idea ?? The idea of recursion is 
  48.    probably a wrong track! Please help !!
  49.  
  50.    Why do I want to do this ?? The function func() emits a NOP assembly
  51.    instruction into the instruction stream. The code is for a slow 8051 
  52.    micro controller  with 1 us instruction cycle, and the NOPs are used 
  53.    for timing. DoFunc(5) would give me 5 us delay, in just 5 bytes of code !!
  54.  
  55. Surprising. Does your compiler optimize away the call to func?
  56. Otherwise, you would at least get a call and a return and not a single
  57. nop. If it does optimize away the call to func, why does it leave a
  58. nop behind?
  59.  
  60. In any case, things like this are not possible in portable C. You can
  61. of course study your particular compiler and get it to do whatever it
  62. can do. The resulting program should not be called C, however :-)
  63.  
  64. Cheers
  65. Tanmoy
  66. --
  67. tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
  68. Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
  69. Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
  70. <http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
  71. internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
  72. fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]
  73.